<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => "I wish that the $a[SQL] standard was actually adhered to",
	'<{body}>' => <<<END
<p>
	After cleaning up the configuration and use of name spaces in the spider, I started work on abstracting the database interactions.
	That way, it would be possible to build a class for each type of database and use whichever class was needed for a given type of database.
	As classes, new database types could be added easily and database-specific logic would not need to be messily strewn about throughout the spider&apos;s main logic.
	I started by trying to build a class to abstract away the <code>\\mysqli</code> class&apos; methods, keeping a copy of an actual <code>\\mysqli</code> class instance as a property of my class.
	I quickly realized that this was the wrong way to build my class though.
	My class should extend the <code>\\mysqli</code> class, allowing instances to to have the full range of functionality available to both <code>\\mysqli</code> objects and object of classes implementing my database interface.
</p>
<p>
	While working on the MySQL implementation of my database interface, I quickly ran into an issue that I had not before: MySQL does not have support for boolean data.
	A database should reasonably be able to store a boolean value, so I had added that to the interface, but now it was being problematic.
	It seems that MySQL does not have basic boolean support! I could implement the feature using a single-digit unsigned integer, a string, or even as a single bit itself, but that does not fix the issue.
	When retrieving the data later, how can I tell the difference between a boolean and data that is actually meant to be whatever type of data I have implemented the boolean as? I could implement all data types as strings, use the first character as a flag to tell what type of data is being used, and perform my own processing, but that would remove much of the database-specific optimization that MySQL (and later database applications that I work with) probably has.
	I could rely on the script making use of the abstraction classes to know that certain data types are not properly implemented and perform needed conversions, but that removes part of the abstraction, as which types function correctly is database-specific.
	I could also implement only strings, so the calling script would know that everything going into or coming out of the database is a string, but that too would remove helpful database-specific internals optimizations.
	Another option would be to rely on the calling script to know what type it was expecting and call appropriate methods such as <code>database::get_bool()</code>, but that would only allow looking data up one grid square at a time.
	Full and partial rows would require performing several lookups, which would cause a serious performance drop.
	I though that this would be a simple subproject, but it might turn into a full-blown project of its own.
</p>
<p>
	I have heard that $a[PHP]&apos;s <a href="https://secure.php.net/manual/en/class.pdo.php"><code>\\PDO</code> class</a> does not provide abstraction; it only provides a consistent interface.
	I also hear that most $a[SQL] database software applications do not correctly implement standard $a[SQL].
	Perhaps using some subset of features, I can use standard $a[SQL] statements in combination with the <code>\\PDO</code> class and actually make progress.
	The catch is, of course, that even if this works, it would only allow use of multiple types of database software back ends to be used; it would not allow a way to use a flat file database structure if desired.
	I think that I will switch to <code>\\PDO</code> tomorrow for the time being.
	If I come up with a better option, I would be happy to switch, but I should not wait around for an idea in the mean time.
	If anyone reports problems in compatibility, I can set up some arrays of database-specific $a[SQL] queries that can be referenced as needed.
	Even better, I could set up separate files for each database application containing only the queries needed by each specific database application, and one can be <code>require()</code>d based on some configuration value.
</p>
END
);
